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(54) Open control system and VPN creation method for multiprotocol ATM switches 



(57) An open control system for an ATM network 
includes a port hardware access interface (PHAI) pro- 
viding access to line card resources, and a signaling 
protocol access interface (SPAI) which is connected to a 
signaling protocol module and implements switch con- 
troller functionality. The PHAI and the SPAI communi- 
cate with each other using at least one mechanism such 
as VPI/VCI, bus-based mechanism and a distributed 
message passing mechanism. A port resource man- 
ager layer (PRML) is provided between the PHAI and 
the SPAI, which logically partitions available resources 
and bundling the available resources into logically con- 
sistent resource modules. 
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Description 

[0001] The present invention generally relates to an 
ATM network system composed of ATM switches, and in 
particular to an open control system and method for s 
implementing open-signaling and virtual private net- 
works (VPNs) within multiprocessor ATM switches. 
[0002] Contemporary network evolution is driven pri- 
marily by a desire for supporting high band-width data 
and for catering heterogeneous quality of service (QoS) io 
requirement of the end-applications. In most occasions, 
this is achieved by devising a set of complex signaling 
protocols that attempt to incorporate the service 
requirements of the existing and conceivable future 
applications. An important example of such a conven- is 
tional signaling protocol is UNI/NNI which was stand- 
ardized by ATM Forum in 1996. See "ATM User 
Network Interlace (UNI) Specification Version 4.0, AF- 
SIG-0061.000," ATM Forum, July 1996; and "Private 
Network-Network Interface Specification version 1.0, 20 
AF-PNNI-0055.000," ATM Forum, September 1996. 
Several other solutions to the signaling problem have 
also been proposed. See "SPANS UNI: Simple Protocol 
for ATM signaling; Release 3.0," FORE Systems Inc., 
July 1995; A. Iwata et al, "ATM Connection and Traffic 25 
Management Schemes for Multimedia Internetworking," 
Communications of the ACM, vol. 3, pp. 501-508; S. 
Rooney, "An Innovative Control Architecture for ATM 
Networks," Proceedings of IM'97, San Diego, May 
1997; and M. Veeraraghavan, T R La Porta and W. S. 30 
Lai, "An Alternative Approach to Call/Connection Con- 
trol in Broadband Switching Systems." IEEE Communi- 
cations Magazine, November 1995, pp. 90-95. 
[0003] The above-mentioned protocols have several 
problems. The approach of signaling standardization, 35 
followed in these conventional protocols, ignores a cur- 
rent trend of the applications evolving rapidly in a rela- 
tively network-independent manner. An inevitable and 
undesirable consequence is that a new application may 
not always be supported by the underlying control pro- 40 
tocol in the most optimal way. It should be noted that the 
terms control and switching have been used inter- 
changeably in this disclosure. 
[0004] The World Wide Web (WWW) provides a case 
in point. When there is a requirement to obtain multiple as 
bursts of short data segments from multiple destina- 
tions, there is no optimal support by the standardized 
ATM signaling protocols. See P. Newman et al, "Row 
Switching: To Switch or Not to Switch," NSF Workshop 
on internet Statistics Measurements, March 1996. The so 
reason for such a sub-optimal support is that UNI/NNI 
signaling requires an end-to-end ATM connection to be 
setup before any IP data can be transported through it. 
[0005] It was shown that a new control protocol, called 
IP Switching, can reduce the startup data access ss 
latency while being able to exploit the fast switching fea- 
tures which are inherent to ATM. See P. Newman et al, 
"Flow Switching: To Switch or Not to Switch," NSF 



Workshop on Internet Statistics Measurements, March 
1996; and A. Acharya et al, "IP Switching Over Fast 
ATM Cell Transport (IPSOFACTO)," Proceedings of 
IEEE Globecom '97, Phoenix, Arizona. December 
1997. 

[0006] Another notable example that reveals signaling 
limitation is the support of location independent applica- 
tions over fixed ATM infrastructure. It has been shown 
that major augmentations to ATM signaling are neces- 
sary before mobility can be supported within ATM. See 
A. Acharya, S. K. Biswas. L J. French, J Li and D. Ray- 
chaudhuri, "Handoff and Location management 
Schemes for Mobile ATM Networks," Proceedings off 
the 3rd International Workshop on Mobile Multimedia 
Communications, Princeton, NJ, September 1996. 
[0007] Standard ATM signaling can be used as a 
means for supporting the existing Personal Communi- 
cation Services (PCS) over ATM, However, such an 
approach is complex and time-consuming. See S. K. 
Biswas and V. Thirumalai, "A Framework for PCS Serv- 
ice Integration within ATM Networks," NEC USA Techni- 
cal Report, February 1998. In general, whenever a new 
application calls for non-standard end-to-end control 
information exchange, either the standard UNI/NNI sig- 
naling protocol needs to be enhanced or the existing 
signaling protocol needs to be replaced by a custom- 
ized new protocol. 

[0008] Protocol replacement is impractical because it 
hurts interoperability and prevents protocols to be back- 
ward compatible. On the other hand, service specific 
signaling enhancement suffers from large standardiza- 
tion delay. Further, repeated enhancements of a control 
protocol can result in a complicated protocol that will 
end up as being difficult to keep track of. 
[0009] A conventional solution to this problem is 
the opening of the signaling framework, so that mul- 
tiple call-control protocols can coexist within the 
same physical ATM network. See J. E. V D. 
Merwe and I. M. Leslie, "Switchlets and Dynamic Vir- 
tual ATM," Available from: http://vmw.cL cam. ac. 
uk/Research/SRG/dcan/papers/im97_switchlets.ps.gz. 
The essence of this idea is defining a simple low level 
hardware control interface that can be used by multiple 
signaling protocols to exercise control on the physical 
switch. 

[001 0] It is also shown that such a framework can be 
extended to create multiple soft switches within a 
physical switch where every soft switch is controlled 
by a specific control protocol. See J. E. V. D. 
Merwe and I. M. Leslie, "Switchlets and Dynamic Vir- 
tual ATM," Available from: http://www.cl. cam. ac. 
uk/Research/SRG/dcan/papers/im97_switchlets.ps.gz. 
Such a mechanism also provides a means for creating 
multiple Virtual Private Networks (VPN) within a single 
physical infrastructure. See C. Scott, P. Wolfe and M. 
Erwin, "Virtual Private Networks," IEEE Computer Soci- 
ety Press, February 1998. 

[001 1 ] In recent years it has been observed that in 
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addition to increased call volume, the call control proto- 
cols are becoming increasingly complex. See B. Stiller, 
"A Survey of UNI Signaling Systems and Protocols for 
ATM Networks," ACM Computer Communication 
Review, vol. 25, pp. 21-23. It is more so for the services 5 
like mobility management, multiparty communication 
and others which require after-setup control to maintain 
and enhance an already established connection. A 
close look to the switch evolution process reveals that 
while the switching capacity of the data path is growing 10 
in keeping with the increasing traffic requirement, most 
of the switch architectures still rely on a centralized 
switch controller CPU for signaling protocol execution. 
As a result, with increasing control complexity the 
switches may soon run into the problem of being con- 15 
trol-bottlenecked while still having the data switching 
capacity. 

[001 2] An obvious way to tackle this problem is to dis- 
tribute the control processing load among multiple 
processing entities within and outside the switch. In one 20 
such approach the control processing for a switch is 
done outside in a general purpose switch controller 
machine. See P. Newman et al, "Ipsilon's General 
Switch Management Protocol Specification Version 
1.1," internet RFC 1987, August 1996. Although this 25 
technique serves as a short-term solution it does not fit 
in a more realistic and desired scenario where the 
processing capabilities are expected to be within a 
switch rather than outside it. It is believed that the future 
generation switching hardware to come with per-port 30 
processing capabilities. See R. Dighe, "Computing 
Architecture for Next-generation Switches: Draft Pro- 
posal," NEC USA internal Document, May 1996. There- 
fore, a more general approach where no assumption is 
made about the physical locations of signaling protocol 35 
executions is required. Depending on the instantaneous 
signaling load on a switch, a particular protocol can be 
run on any of the available processors within the switch 
or even outside. This invention provides an architectural 
framework for implementing location independent ATM 40 
signaling in a multiprotocol switch environment. 
[001 3] Further, any software architecture used should 
provide signaling software modularity. The architecture 
should be engineered in a way so that new control pro- 
tocol stacks can easily be incorporated on-line without 45 
interrupting the existing services. Modularity should 
also allow new control processors to be added in a 
transparent manner so that the management software 
should be able to dynamically incorporate the new proc- 
essors and to redistribute control processing accord- so 
ingly. In order to ensure modularity, part of the software 
needs to be reusable for different switching platforms. 
[0014] Furthermore, with the recent proliferation of 
internet and its services, more and more corporate 
users are relying on the internet for their day-to-day ss 
business requirements. As a result of the customized 
service demands of today's corporate users, together 
with individual security concerns, a desire for private 



networking services is evolving within the enterprise 
internet user community. Introduction of the Virtual Pri- 
vate Networking (VPN) is aimed at offering customized 
network services within the existing internet framework. 
See C. Scott, P. Wolfe and M. Erwin, "Virtual Private 
Networks," IEEE Computer Society Press, February 
1998 and T. Kato, K. Omachi and S. Tanabe, "BVPN 
(Broadband Virtual Private Network): A Flexible, High- 
speed, Enterprise Network Architecture", Proceedings 
of the Fifth IEEE Computer Society Conference on 
Future Trends of Distributed Computing System, 
August 1995. 

[001 5] At the highest level of abstraction, a VPN is a 
logical network which when appropriately configured, 
can be assigned to a specific multi-site user for the cus- 
tomized service requirements of the user. A logical net- 
work is considered to be an overlay on an existing 
physical network and the resources associated with the 
physical network. An example of a simple VPN is a Per- 
manent Virtual Circuit (PVC) with resources assigned to 
it. See "ATM User Network Interface (UNI) Specification 
Version 4.0, AF-SIG-0061.000," ATM Forum, July 1996 
and "Private Network-Network Interface Specification 
version 1.0, AF-PNNI-0055.000," ATM Forum, Septem- 
ber 1996. Once a PVC is allotted to a network customer, 
within the constraints of the resources reserved for the 
PVC, the customer can use the virtual circuit completely 
at the user's discretion. Possible customizations include 
data multiplexing within the PVC, data compression and 
end-to-end data encryption. An essential purpose of 
having a VPN is to provide customized services to a 
specific customer without affecting the other users of 
the network. 

[0016] In the next lower level of abstraction, the VPN 
uses multiple PVCs for creating an overlay mesh. See 
M. C. Chan, H. Hadama and R. Stadler, "An Architec- 
ture for Broadband Virtual Networks under Customer 
Control," Proceedings of the IEEE Symposium on Net- 
work Operations and Management, April 1996. Once 
such a mesh VPN is configured, the owner of the mesh 
VPN can run a customized signaling protocol to set up 
connections within the mesh VPN. For a mesh VPN, 
other customized processes that need to be performed 
include routing, call admission control, cell-level sched- 
uling, accounting, billing and several other ATM man- 
agement-plane functions. See D. Ginsburg, "ATM: 
Solutions for Enterprise networking," Addison- Wesley, 
Harlow, UK, 1996. 

[0017] Conventionally, many forms of VPNs have 
been defined for both IP and ATM-based internet back- 
bones. See "A Framework for IP Based Virtual Private 
Network," internet Draft of Internet Engineering Task 
Force, February 1998 and P. Coppo, M. D'Ambrosio 
and V. Vercellone, "The A-VPN Server: A Solution for 
ATM Virtual Private Networks", Proceedings of Singa- 
pore ICCS'94, November 1994. Functionally, these 
VPNs range from simple end-to-end tunnels (e.g. PVC) 
to a full-blown overlay of resource-reserved mesh, as 
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described above. Regardless of the model adopted, a 
network switching device that provides a clean mecha- 
nism for partitioning and reserving its resources for the 
participating VPNs within the network is required. 
[0018] In order to solve the above-mentioned prob- s 
lems, it is an objective of the present invention to use 
the idea of open control interface to provide an open 
control system and method that is capable of supporting 
multiple signaling protocols within multi -processor ATM 
switches. *o 
[001 9] Another objective of the present invention is to 
provide an architecture for partitioning and reserving 
resources within ATM switches for creating and main- 
taining VPNs. 

[0020] According to an aspect of the present inven- 15 
tion, an open control system for an ATM network includ- 
ing a plurality of ATM switches is characterized by a port 
hardware access interface (PHAI) providing access to 
line card resources, and a signaling protocol access 
interface (SPAI) which is connected to a signaling proto- 20 
col module and implements switch controller functional- 
ity. The PHAI and the SPAI communicate with each 
other using at least one mechanism depending on a 
processing platform used. 

[0021 ] A port resource manager layer (PRML) may be 25 
preferably provided between the PHAI and the SPAI, 
which logically partitions available resources and bun- 
dling the available resources into logically consistent 
resource modules. The available resources may include 
switching bandwidth, VPI space, VCI space, input buffer 30 
space, output buffer space and local processing cycles 
for cell-level scheduling. 

[0022] The PRML may partition the available 
resources based on one of a static and dynamic policy 
into a plurality of partitioned resource modules, wherein 35 
each of the plurality of partitioned resource modules is 
assigned to a specific administrative entity. 
[0023] In this manner, the coupling between the switch 
controller and the line card hardware can be loosed 
while maintaining standard control interfaces between 40 
them. Such an approach provides a framework for 
implementing distributed signaling and a clean way of 
supporting multiple control protocols in future genera- 
tion switching devices. Further, signaling software mod- 
ularity can be achieved. 45 
[0024] According to another aspect of the present 
invention, the PRML provides a mechanism for logically 
partitioning available resources and bundling a parti- 
tioned resource into VPN (virtual private network) spe- 
cific resource module (VPNRM). The VPNRMs are so 
allocated to at least one VPN which is overlaid on the 
ATM network. Each of the VPNRMs is owned by one of 
the VPNs and the one of the VPNs may be free to 
choose an authentication and security model for 
accessing available resources. 55 
[0025] By partitioning and reserving resources within 
ATM switches as described above, VPNs are created 
and maintained and further VPN software modularity is 
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provided, allowing the reuse of part of the VPN software 
on varieties switching platforms. Furthermore, a frame- 
work can be achieved for VPN service level manage- 
ment for creation, termination and maintenance of the 
VPNs. 

FIG. 1 is a schematic diagram shewing the configu- 
ration of an ATM network composes of ATM 
switches each comprised of multiple line-cards 
each equipped with a microprocessor, and further 
showing the switch architecture that is targeted for 
implementing an open control and VPN architec- 
ture according to the present invention; 

FIG. 2 is a schematic diagram showing a basic 
open control software architecture according to the 
present invention; 

FIG. 3 is a schematic diagram showing a first 
arrangement for supporting a port-resource man- 
agement layer that partitions the port-resources 
according to a first embodiment of the present 
invention; 

FIG. 4 is a schematic diagram showing a second 
arrangement for supporting multiple ATM control 
protocols on a switch port according to the first 
embodiment of the present invention; 

FIG. 5 is a schematic diagram showing a software 
architecture for a specific switch hardware platform 
according to a second embodiment of the present 
invention; 

FIG. 6 is a schematic diagram illustrating steps in 
on-line protocol downloading, according to the 
present invention; 

FIG. 7 is a schematic diagram showing an example 
of a distributed call processing and call admission 
control according to the present invention; 

FIG. 8A is a schematic diagram showing an archi- 
tecture allowing a mechanism for local call control; 

FIG. 8B is a schematic diagram showing an archi- 
tecture allowing a mechanism for remote and trans- 
parent call control according to the present 
invention; 

FIG. 9 is a schematic diagram showing the compo- 
nents and procedures for distributed switch man- 
agement according to the present invention; 

FIG. 1 0 is a schematic diagram showing a preferred 
embodiment of the architecture of the present 
invention using a flexible programmable ATM 
access multiplexer; 
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FIG. 11 is a block diagram showing a conceptual 
architecture of an ATM access multiplexer accord- 
ing to the preferred embodiment of the architecture 
of the present invention; 

FIG. 12 is a block diagram showing a system archi- 
tecture of an ATM access multiplexer according to 
the preferred embodiment of the present invention; 

FIG. 13 is a block diagram showing a circuit config- 
uration of a universal interface card (UIF) according 
to the present invention; 

FIG. 1 4 is a diagram showing an example of a VPN 
model on ATM switches in an ATM network; 

FIG. 15 is a schematic diagram showing port 
resource management for supporting VPNs 
according to a third embodiment of the present 
invention; 

FIG. 16 is a schematic diagram showing multiple 
protocol support for VPNs according to the third 
embodiment of the present invention; 

FIG. 1 7 is a schematic diagram showing a preferred 
embodiment of a VPN system according to the 
present invention; and 

FIG. 18 is a diagram illustrating steps in creating 
VPN services on a switch port. 

ATM SWITCHING SYSTEM 

[0026] Referring to FIG. 1, an ATM network is com- 
posed of a plurality of ATM switches S1, S2, S3 and so 
on. An ATM switch has a core switch fabric 1 1 , which is 
controlled by a switch controller 12 including a proces- 
sor 13. The core switch fabric 1 1 connects the ATM net- 
work and a plurality of line cards LC r LC N which are 
respectively associated with subscriber lines 1-N. The 
respective line cards LC r LC N have microprocessors 
PROC r PROC N therein. As will be described hereinaf- 
ter, the open-software architecture and the resource 
and protocol management for VPN can be implemented 
on the processors within the multiprocessor ATM 
switches. 

OPEN CONTROL IMPLEMENTATION 

[0027] Following is a list of several key features of an 
embodiment of an architecture according to the present 
invention: 

Open-control within multiprocessor ATM switches; 
Distributed call-processing across the switch proc- 
essors; 

• Dynamic control-load balancing and sharing; 
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• Modular and reusable signaling stack design; 
Dynamic control protocol down-loading ; 

• Multi-protocol (ATM, IP-over-ATM, IPSOFACTO, 
MPLS etc.) support at both switch and port level; 

5 and 

Generic port-resource management for supporting 
higher layer services like Virtual Private Network 
(VPN). 

10 [0028] A conventional ATM switch contains an internal 
controller that is connected to one of the switch ports. 
When a signaling message (e.g. Q.2931 setup mes- 
sage) is received through a port, the corresponding line 
card hardware detects that the message requires con- 

is trol processing by looking at the corresponding VCI. At 
this stage, the received message is immediately for- 
warded to the switch controller for control processing, it 
should be noted that it is the switch controller that sub- 
sequently executes a relevant signaling protocol to 

20 route the connection and to set up the VPI/VCI within 
the relevant switch ports. 

[0029] Since most of the existing switches do not han- 
dle multiple signaling protocols, the control coupling 
between the switch controller and the line card hard- 
25 ware is designed to be rigid for improved performance. 
A key goal of the present invention is to loosen up the 
coupling while maintaining standard control interfaces 
between the switch controller and the line card hard- 
ware. Such an approach provides a framework for 
30 implementing distributed signaling and a clean way of 
supporting multiple control protocols in future genera- 
tion switching devices. Note that this distribution 
involves communication cost and practitioners ought to 
be careful during the implementation to keep this cost 
35 as low as possible. Otherwise the benefits of load distri- 
bution will not be seen. 

1. Control Interfaces 

40 [0030] FIG. 2 shows an embodiment implementing the 
open control system according to the present invention. 
Here, the primary components of interest are a pair of 
standard interfaces which are termed as Port Hardware 
Access Interface (PHAI) 101 and Signaling Protocol 
45 Access Interface (SPAI) 102. A PHAI 101 provides 
access to the low-level line card resources including: 

• VCI/VPI table; 

• input/output buffers; and 
so • the cell scheduling parameters. 

[0031 ] In addition, it is also possible to obtain the line 
card configuration and various traffic and error statistics 
information through this interface. In general, given the 
55 right access permissions, any control entity can manip- 
ulate the line card resources through the PHAI interface 
101. The SPAI interface 102 implements the controller 
counterpart of the PHAI interface 101. Using this inter- 
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face, line cards 10, and LC N deliver control messages 
to a signaling protocol module 103. For the protocol 
module, the PHAI also serves as a general-purpose 
mailbox through which various asynchronous alarm 
events from the line cards are delivered. 
[0032] Once these PHA! and SPAI interfaces 1 01 and 
102 are specified and exported out, the physical loca- 
tion of the signaling module 103 beoomes functionally 
insignificant. The signaling module 103 can run on a 
local switch controller 12, on a remote workstation or 
even on a processing element within one of the line 
cards. Such an implementation helps in achieving total 
distribution of the control processing functions. Also, 
since the PHAI interface 101 is specified and exported 
out of the line cards, it is possible for a number of differ- 
ent signaling protocol modules to exercise simultaneous 
control on different connections though a single line 
card. The necessary resource partitioning/management 
layer and its protection issues are discussed in the next 
subsection. 

[0033] It should be noted that no assumptions are 
made regarding the underlying communication mecha- 
nisms used by the two interfaces PHAI 101 and SPAI 
102. The communication mechanism used depends 
completely on the processing platform. If the switch 
controller (either inside or outside the switch) is con- 
nected to one of the switch ports then a default VP/VC 
between a specific pair of PHAI and SPAI can be used. 
Using such an approach, the communication cost can 
be kept low. 

[0034] On the other hand, if the target hardware pro- 
vides a dedicated control bus between the line cards 
and the internal switch controller(s) then using a bus- 
based communication mechanism will prove to be less 
expensive. See R. Dighe and V. Thirumalai; "DSLAM 
Functional Architecture, " NEC USA Technical Report, 
January 1998. Yet in another situation, if the signaling 
protocol module is located in a remote computing entity 
then a general purpose distributed message passing 
mechanism like RPC will be more appropriate. See 
"Network Programming Guide," Sun Microsystems, 
Mountain View, CA, 1990 or ORB See S. Vinoski, 
"CORBA: Integrating Diverse Applications within Dis- 
tributed Heterogeneous Environments", IEEE Commu- 
nications Magazine, February 1997, pp. 46-55. In fact, 
in the embodiments described in the present specifica- 
tion, a combination of all the above-mentioned mecha- 
nism is used depending on the communication 
performance requirements. 

2. Port-Resource Management Layer (PRML) 

[0035] Referring to FIG. 3, a thin layer of software, 
namely Port-resource Management Layer (PRML) 204, 
is added between the PHAI interface 101 and the SPAI 
interlace 102. Purpose of this layer is to provide a mech- 
anism for logically partitioning the available resources 
and bundle them into logically consistent resource mod- 
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ules. Once partitioned, these resource modules are 
allocated to specific administrative entities which are 
active on the corresponding port. In addition, this layer 
also provides the security features needed to perform 
5 access validation of the PHAI interfaces. The port-spe- 
cific resources, managed by a port PRML, are: 

• switching bandwidth, 

• VPl/VCI space, 

10 • input/output buffer space and 

• local processing cycles required for cell-level 
scheduling. 

[0036] Based on a predetermined policy (static and/or 
is dynamic), the PRML 204 partitions these resources and 
allocates a part of it to a partitioned resource module 
201 , whenever it is created. Each such resource module 
is owned by a specific administrative entity (e.g. a VPN) 
and the administrative entity is free to choose its own 
20 authentication and security model for the access to the 
resources. In addition, a resource module exports a 
Module-specific Secured Interface (MSSI) 203 which is 
used by the protocol signaling module 103 for control- 
ling the partitioned resource module 201. 
25 [0037] An MSSI interface 203 offers all the PHAI func- 
tionalities with added inter-module security and 
resource protection. Each resource module is identified 
by three parameters, namely, 

30 • its associated port-id, 

• protocol-type and 

• an owner-id. 

While the port-id simply refers to the physical port on 
35 which the resource module is created, the protocol-type 
points to a particular type of signaling protocol module 
which should control that particular resource module. 
The owner-id indicates to the administrative owner of 
the module and its associated resources. For example, 
40 in a virtual private network (VPN) scenario, this owner- 
id points to the VPN which the resource module belongs 
to. 

[0038] Within the port-resource management layer 
(PRML) 204 of each port, there is a Port Resource Man- 
45 ager (PRM) 202 which is responsible for partitioning the 
available resources and allocating them to the resource 
modules. This entity is also responsible for creating the 
resource modules. 

[0039] In order to explain how all the components in 
so PRML work together, an example scenario where a 
physical port of a switch is shared by multiple virtual pri- 
vate networks (VPN) is described herein. During the 
creation of a VPN, the port resource manager (PRM) 
202 corresponding to the port is informed, using a 
55 higher layer protocol (not explained herein), about the 
signaling protocol which the VPN is stated to use on that 
port. The port resource manager (PRM) 202 also 
receives information about the amount of line card 
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resources requested by the VPN. Based on this infor- 
mation, the PRM 202 creates a resource module and 
allocates desired amount of line card resources to the 
newly created module. Then a resource module-to-pro- 
tocol binding is established so that the resource module 5 
knows which protocol module to interact with for its con- 
trol purposes. 

[0040] This point onwards, a VPN resource module 
and its associated signaling protocol module together 
control and maintain the connections which come 10 
through the residing port and belong to the logical net- 
work, owned by that particular VPN. Any inter-module 
(inter-VPN, in this example) resource violation are 
trapped at this layer and appropriate corrective actions 
taken. Upon receiving the termination instruction from 75 
higher layer management entities, the port resource 
manager deletes the corresponding resource module. 
In this scenario, it will happen when the VPN decides to 
withdraw services from this particular port of the switch. 
Once a resource module is terminated, its occupied 20 
resources are reclaimed by the port resource manager 
and is used for further allocation to the future resource 
modules. 

[0041 ] The present invention also provides a signaling 
message dispatching mechanism within the PHAI 101 25 
of each line card. When a connection setup message is 
received, the line card hardware is required to deliver 
the message to the appropriate MSSI interface 203 
using the appropriate resource module. This is done by 
partitioning the available signaling VPI/VCI space of a 30 
particular switch port. Consider a scenario where two 
VPNs need to run UNI/NNI signaling on a single switch 
port but each require independent control on their 
respective resource modules. This is achieved by parti- 
tioning the signaling VPI/VCI space for different owners. 35 
An example of this will be to use (VPI 0, VCI 5) as the 
signaling channel for VPN-1 and to use (VPI 0, VPI 6) 
as the signaling channel of VPN-2. In situations where 
this owner-specific VPI/VCI preassignment is not 
acceptable, a higher layer messaging mechanism is 40 
necessary for performing signaling message demulti- 
plexing. 

3. Supporting Multiple Protocols 

45 

[0042] FIG. 4 shows an arrangement for supporting 
multiple ATM control protocols on a switch port. A list of 
such signaling protocols includes: 

• ATM forum standard UNI/NNI; so 

• Distributed ATM signaling (See M. Veeraraghavan, 
T. F. La Porta and W. S. Lai, "An Alternative 
Approach to Call/Connection Control in Broadband 
Switching Systems," IEEE Communications 
Magazine, November 1995, pp. 90-95); ss 

• Circuit Emulation (See D. Ginsburg. "ATM: Solu- 
tions for Enterprise networking," Addison- Wesley, 
Harlow, UK, 1996); 



. IP-over-ATM (RFC 1577, 1483); 

• IP-over-ATM using MPOA (See "Multi-Protocol 
Over ATM Version 1.0, AF-MPOA-0087.000," ATM 
Forum, July 1997); 

Ipsilon IP-Switching (See P. Newman et al, "Row 
Switching: To Switch or Not to Switch," NSF Work- 
shop on Internet Statistics Measurements, March 
1996); 

• Tag switching (See D. Ginsburg, "ATM: Solutions 
for Enterprise networking,*' Addison- Wesley, Har- 
low, UK, 1996); 

• CSR switching (See D. Ginsburg, "ATM: Solutions 
for Enterprise networking," Addison- Wesley, Har- 
low, UK, 1996); 

• Ipsofacto (See A. Acharya et al, "IP Switching Over 
Fast ATM Cell Transport (IPSOFACTO)," Proceed- 
ings of IEEE Globecom '97, Phoenix, Arizona, 
December 1997); 

. IETF MPLS; and 

• PCS-over-ATM (See S. K. Biswas and V. Thiruma- 
lai, "A Framework for PCS Service Integration 
within ATM Networks," NEC USA Technical Report, 
February 1998 (e.g. GSM-over-ATM)). 

[0043] Note that there is no one-to-one coupling 
between particular protocol signaling modules 103.1 to 
103.M and a partitioned resource module 201 on the 
port. Multiple resource modules can use a single proto- 
col signaling module to execute their signaling require- 
ments. The reverse however is not true; meaning a 
resource module is never allowed to communicate with 
multiple protocol modules even if their protocol types 
are same. By such a mechanism, it is ensured that with 
appropriate access authentication, multiple administra- 
tive entities on a switch-port can use the same control 
protocol but each of the administrative entities should 
be allowed to use at most one control protocol. 
[0044] Whenever a partitioned resource module 201 
is registered with a protocol object, it sends its own allo- 
cated resource information to the protocol module. The 
control protocol module uses this resource information 
to allocate the following to the connections, belonging to 
the resource module: 

• VPI/VCI; 
Buffers; 

Cell-level scheduling priority; and 

• to execute Call Admission Control (CAC). 

[0045] Note that the protocol modules are line-inde- 
pendent, and no mapping between a module and its 
host hardware is assumed. A resource module on any 
port is able to use a signaling module which is running 
either on the same line card or on a different line card or 
on an internal switch controller processor or even on a 
remote workstation. The port resource managers are 
also designed to be hardware and location independ- 
ent. As long as a line card implements and runs the 



15 



20 



13 EP 0 977 457 A2 14 



PHAI interface 101, it should be capable of being con- 
trolled and managed by a remote PRM entity. This fea- 
ture is particularly useful for switches which do not have 
processing capabilities on their line cards. However, for 
line cards with processors it is preferable to run the 5 
PRM modules locally. 

[0046] At a given point of time, the switch may not nec- 
essarily have all the necessary control protocols resi- 
dent locally. This calls for a dynamic protocol loading 
and referral arrangement, which will be explained later. 10 
[0047] As shown in FIG. 4, each switch contains a pro- 
tocol manager module (PMM) 301 which is responsible 
for protocol downloading, internal processing and mem- 
ory resource administration and other management 
plane activities. Each partitioned resource module is 
(PRM) 201 talks to the PMM 301 through a special man- 
agement interface. This interface is used for informing a 
PRM about the necessary resource modules and their 
resource requirement information. The present inven- 
tion does not make any assumption about the physical 20 
location of the PMM either. Depending on the available 
memory and processing resources the PMM can run 
locally on a switch controller CPU or on a remote proc- 
essor situated outside the switch. 

25 

OVERALL ARCHITECTURE 

[0048] Referring to FIG. 5, the hardware architecture 
includes processors PRO^ to PROC N on the line 
cards LC^ to LC N and one or more internal control proc- 30 
essors PROC 13.1 and PROC 13.2 on switch control- 
lers 12.1 and 12.2, respectively. In this scenario it is 
most likely, and desirable, that the PRM 202 of a partic- 
ular port runs locally on the corresponding line card. 
Some of the signaling protocol modules are also 35 
expected to run on the line cards. This hardware alloca- 
tion for a software module depends on the usage load of 
a particular module. Because of these factors, the 
present invention keeps the allocation dynamic. For 
instance, it would be beneficial to run a UNI/NNI module 40 
on each line card processor, because each port is 
expected to support at least one resource module 
requiring UNIVNNI signaling. On the other hand, an IP- 
switching control module is too heavy-weight and 
resource intensive to run on a line card processor and 45 
should be run either on one of the local switch control- 
lers or on a remote processor. See A. Acharya et al, "IP 
Switching Over Fast ATM Cell Transport (IPSO- 
FACTO)," Proceedings of IEEE Globecom '97, Phoenix, 
Arizona, December 1997. so 
[0049] The present invention allows multiple instances 
of protocol modules of a single type to exist simultane- 
ously. An example of such a multiple existence of port 
specific UNI/NNI signaling modules is shown in FIG. 5 
(See 403.1 and 403.2). This arrangement enables the ss 
supporting of another useful mechanism, which is dis- 
tributed call control processing within a switch. In a nut- 
shell, distributed call processing allows the control, 



including call admission, for a new connection to be exe- 
cuted by multiple protocol modules residing in different 
processors. This mechanism, when implemented care- 
fully, is capable of enhancing the call handling capacity 
of a given switching hardware. 
[0050] Two new components, namely, the Inter Object 
Messaging Platform (IOMP) 401 and the CORBA agent 
402 are shown in FIG. 5. The IOMP 401 provides a uni- 
form inter-module communication interface within the 
switch. While being light-weight, this should provide a 
clean function-call type communication interface. For 
implementing IOMP 401 this embodiment uses a com- 
bination of: 

Permanent virtual circuits, 

• Operating system Inter Process Communication 
(IPC) calls, 

• Raw IP messages, and 

• Remote Procedure Calls (RPC). 

[0051] The CORBA agent 402 is responsible for a 
number of management operations including protocol 
downloading from the network, remote switch manage- 
ment and possible new service creation within the 
switch. See S. Rao, J.-R Redlich, M. Suzuki and S. 
Weinstein, n A Distributed Object Architecture for QOS- 
Sensitive Networking," Proceedings of OPENARCHVd, 
San Francisco, CA, April 1998. The CORBA agent will 
be explained further. 

[0052] An important design decision for this architec- 
ture is choosing an appropriate operating system. From 
the discussion so far it became apparent that the suc- 
cess of the architecture depends to some extent on the 
clean separations between multiple threads of protocol 
executions. This calls for an OS platform which is capa- 
ble of supporting light-weight processes, implementing 
the protocol and the manager modules with their asso- 
ciated interfaces. Given the extent to which the present 
invention separates the protocol functions and map 
them to processes, frequent context switchings are 
expected. Based on this realization, a simple process 
structure is chosen where a process context should not 
contain anything substantially more than the CPU regis- 
ters and a pointer to the process's stack Considering 
these, a real-time embedded OS which should run on a 
single address space and, if necessary, should adapt 
itself in a multiprocessor mode is the most preferred. A 
list of such possible OSs includes pSOS, VxWorks, 
NEC RTOS and ROME embedded operating systems 

PROTOCOL DOWNLOADING AND REFERRAL 

[0053] It is assumed in the present architecture that at 
any given point of time, all the relevant protocol modules 
are not necessarily resident within the switch. Instead, 
they are selectively down-loaded from the network, as 
required. The purpose of such a dynamic downloading 
is to optimize the utilization of the available processing 
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and memory resources within the switch. Also, new ver- 
sions of a particular control protocol can be seamlessly 
loaded this way, without causing any service disruption 
for the existing working protocols. 
[0054] Referring to FIG. 6, there are two possible sit- s 
uations when an on-line protocol downloading may be 
invoked. The first one refers to a scenario where a port 
resource manager (PRM) is instructed to create a new 
resource module. An example of this would be when a 
VPN needs to be created on the specific port. At this 10 
stage, after creating a resource module and its associ- 
ated MSSI, the PRM 202 sends a protocol reference 
request indicated by reference (1) to the switch PMM 
301 as shown in FIG. 6. 

[0055] If the necessary protocol module, GSM MAP in 15 
this example, is not already available within the switch, 
then the PMM 301, in coordination with the CORBA 
object 402 as indicated by references (2) and (3), down- 
loads the GSM MAP module 501 from the network and 
puts it on a suitable processing platform as indicated by 20 
references (4) and (5). See M. Mouly and M. B. Pautet, 
"OSM System for Mobile Communications," Published 
by the authors, 1992. Note that the PMM 301 maintains 
an account of the available processing and memory 
resources and based on that it selects a processing 25 
platform in order to achieve the right processing load 
balancing. 

[0056] In order to make room for a new control proto- 
col, the PMM 301 may choose to delete a currently 
unused module and inform the relevant PRMs about 30 
this deletion. When local secondary storage is available, 
instead of deleting, the PMM 301 may also swap exist- 
ing unused protocols to make room for the new ones. In 
the present example, after the GSM MAP module 501 is 
downloaded and initialized, a protocol reference reply is 35 
sent to the PRM 202 as indicated by reference (6) 
which, in turn, passes the reference to the correspond- 
ing MSSI interface. This point onwards, the concerned 
resource module directly communicates with the GSM 
MAP module 501 for performing all its GSM-over-ATM 40 
call processing. 

[0057] The other on-line downloading scenario occurs 
when a new protocol is specifically requested by the 
user. Consider a situation where, through a meta-sign- 
aling mechanism, an end-station requests the switch for 45 
the next connection to be handled by a specific signal- 
ing protocol. An example of such a request would be the 
case where a user instructs the ATM network that all its 
web browsing traffic should use a specific IP switching 
protocol like IPSOFACTO. See A. Acharya et al, "IP so 
Switching Over Fast ATM Cell Transport (IPSO- 
FACTO), " Proceedings of IEEE Globecom '97, Phoenix, 
Arizona, December 1997. When the request is received 
by the switch and subsequently by a PMM, the PMM 
may realize that there is no local copy of the requisi- 55 
tioned control protocol in the switch. At this point, the 
PMM starts downloading the necessary IP switching 
module in the switch and also sends the necessary ref- 
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erences to the corresponding PRMs. 
DISTRIBUTED CALL CONTROL 

[0058] Call processing load balancing is achieved by 
distributing the protocol modules across the available 
processors on both the line cards and the switch con- 
trollers. Even for a single signaling protocol, the present 
invention allows the protocol functions to be partitioned 
and distributed in a modular fashion. 
[0059] FIG. 7 shows an example of such a partition- 
ing, where a single UNI/NNI protocol module is allo- 
cated for each of the two switch ports. When a 
connection request arrives through the incoming port, 
the message is sent to UNI/NNI module-1 403.1. The 
UNI/NNI module-1 403.1 then executes the call admis- 
sion control (CAC) for the incoming port. A decision on 
CAC is made based on the requested Quality of Serv- 
ices (QoS) and the available buffer and CPU resources 
available at the incoming port. If a decision is made to 
admit the call, the module-1 403.1 executes routing for 
deciding the output port. At this stage, the module-1 
403.1 contacts the relevant outgoing port UNI/NNI mod- 
ule-2 403.2 and the latter performs another CAC for the 
outgoing port. If the second CAC also succeeds, then 
the connection request message is forwarded to the 
next-hop switch. Also, the protocol modules now write a 
set of connection specific information within the line 
cards through the respective MSSI interfaces. This 
information includes new VPI/VCI routing entry, allo- 
cated buffer size and the cell scheduling policy. This 
information is sufficient to extract the QoS requirements 
of the newly setup connection. 
[0060] It is important to note that in order for the 
described CAC to work, it is necessary for the protocol 
modules to share the resource availability information 
with the involved resource modules and their MSSI 
interfaces. A straightforward means to achieve such a 
sharing of information would be to have an MSSI send 
its allocated resource list to the protocol module as soon 
as it gets registered with the module. This way, the pro- 
tocol module will have all the necessary information 
locally and a meaningful CAC decision can be made. To 
maintain consistency of the distributed resource data- 
bases, lazy mode update messages are used between 
an MSSI and its peer protocol module. In addition, a 
security mechanism is provided for preventing any 
MSSI from accessing and violating the resource infor- 
mation for another MSSI which is available within the 
same protocol module. 

[0061] As illustrated in FIGs. 8A and 8B, the present 
architecture allows a mechanism for remote and trans- 
parent call control. Consider a situation where an ATM 
switch is operating as an IP router between two logical 
IP subnets (LIS in RFC 1 577). The scenario as shown in 
FIG. 8A shows how routing can be done locally when 
the IP router module 701 is running on a controller card 
12 within the switch. It is shown in FIG. 8B that taking 



EP0977 457 A2 



9 



17 



EP0 977 457 A2 



18 



the routing module 702 to a remote workstation 703 
does not require any architectural change to the basic 
design. It is just that when the protocol referral is per- 
formed, the switch PMM should pass a remote IP router 
reference to the corresponding port resource manager. 5 
This level of functional transparency is achieved by 
using the standard MSSL and SPAI interfaces which are 
designed for the open control framework, as described 
before. 

[0062] The ability to run control protocols remotely 10 
provides a switch more flexibility in terms of its local 
CPU usage. The idea is to run the performance critical 
protocols like mobile ATM locally and to distribute non 
real-time protocols remotely, that is when the local CPU 
cycles are exhausted. is 

DISTRIBUTED SWITCH MANAGEMENT 

[0063] As shown in FIG. 9, a preferred embodiment for 
the distributed switch management according to the 20 
present invention uses a CORBA-based management 
framework. A CORBA module within each switch acts 
like a local agent that coordinates with external entities 
for downloading protocols and other management oper- 
ations. Any remote management and control instruc- 25 
tions for the switch are required to pass through the 
CORBA agent 402. In addition to providing manage- 
ment interfaces, such an arrangement simplifies provid- 
ing security and authenticating external switch access. 
Note that the CORBA agent 402 also has a control inter- 30 
face through which it can talk to the MSSIs on all the 
switch ports. This provides a means for port level man- 
agement. A list of such management operations 
include: 

35 

Remote port configuration; 

Remote virtual private network (VPN) creation ; 

• Resource modules and MSSI interface creation; 
and 

• Port statistics collection. 40 

[0064] The CORBA agent 402 also coordinates with 
the protocol manager module 301 to perform switch 
level management functions like on-the-fly protocol 
downloading, billing and dynamically creating various 45 
virtual services. See S. Rao, J.-P. Redlich, M. Suzuki 
and S. Weinstein, "A Distributed Object Architecture for 
QOS-Sensitive Networking," Proceedings of 
OPENARCH'98, San Francisco, CA, April 1998. 
[0065] Dynamic service creation, a feature of the so 
present invention, allows on-line implementation of new 
services that can be customized for specific service pro- 
viders and/or customers. An example of such a service 
is customized PNNI routing. Consider a situation where 
a switch is required to provide customized routing serv- 55 
ice to a specific organization where all traffic from that 
organization should be routed through a specific output 
port, irrespective of the Quality of Service (QoS) 



requirements and network loading conditions. Using the 
architecture of the present invention, it can be easily 
implemented on the fly. The NMS provides such an 
instruction to the CORBA agent 402 corresponding to 
the switch. The CORBA agent 402, in coordination with 
the local PMM 301, communicates with the relevant 
UNI/NNI module 403 so that the latter can mod- 
ify/enhance its PNNI routing operation accordingly. 

FLEXIBLE PROGRAMMABLE ATM ACCESS MULTI- 
PLEXER 

[0066] In addition to the ATM edge switch, an NEC 
universal ATM multiplexer is an example of application 
platform that can be used for the architecture disclosed 
herein. See G. Ramamurthy, R. Fan, A. Ishi and B. 
Mark, "Next Generation Edge Switch Architecture," 
NEC USA internal Document, Advanced Development 
Department, December 1997 and R. Dighe and V. 
Thirumalai; "DSLA M Functional Architecture," NEC 
USA Technical Report, January 1998. The latter is used 
to illustrate a preferred embodiment of the present 
invention. 

[0067] Referring to FIG. 10, an implementation of the 
described software architecture is shown. The imple- 
mentation disclosed herein is on a Flexible Programma- 
ble ATM Access Multiplexer described in U.S. Patent 
Application Serial No.09/1 84,640, which is incorporated 
herein by reference, and which describes a multi-proc- 
essor switching device functionally. 
[0068] Each port related to the access multiplexer is 
divided into two physically separate cards, namely a 
Line Interface Card (LIF) and a Universal Interface Card 
(UIF). While the line interface card LIF performs all line- 
specific operations (e.g. coding, line delimiting, line 
maintenance etc.), the UIF is responsible for higher 
layer protocol related functions, including, layer-3 proto- 
col termination, cell queuing, traffic shaping and polic- 
ing. The UIF and LIF together provide the functionality 
of a switch port. 

[0069] These switch-ports and the controller card (ele- 
ment management card) communicate through an ATM 
cell bus 901 . An ATM cell bus 901 is chosen for optimiz- 
ing the communication costs among the UIFs and the 
controller card. More about these cards and their func- 
tional descriptions will be described hereinafter. Note 
that each UIF hosts a processor and since there are 
multiple UIFs present in the multiplexer, the device acts 
like a multi-processor switch. This particular hardware 
feature of the multiplexer makes it a suitable implemen- 
tation platform for the open control-software architec- 
ture of the present invention. 

1. Conceptual architecture 

[0070] As shown in Fig. 1 1 , the architecture of a mul- 
tiplexing system based on the present invention incor- 
porates a functional separation of line related functions 
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and protocol related functions. Such a functional sepa- 
ration is accomplished by physically separating a set of 
line interface card (LIF) from a universal interface card 
(UIF) through a frame-based interface 900 that will be 
described later. All line related functions are done at the 5 
LIF while all higher level protocol related processing is 
done at the UIF. 

[0071] Ail the UIFs are of the same type, while the 
structure of LIFs depend on the type of line technology 
used. The number of different LIFs that are provided 10 
depends on the technology available. Here, the follow- 
ings may be included: T1 LIF, T3 LIF, Asymmetric Digital 
Subscriber Line (ADSL) LIF (CAP/DMT), HDSL LIF, 
ADSL-lite LIF, Ethernet LIF, Radio LIFs. 25Mb/s ATM 
LIF, and Cable Modem LIF. The Radio LIFs include glo- 15 
bal system for mobile communications (GSM), code 
division multiple access (CDMA), Wireless ATM, etc. 
[0072] A skilled practitioner will understand that the 
present invention is not limited to the above list. LIFs 
based on technologies that will become available in 20 
future are also within the scope of this invention. 
[0073] A common type of UIF is provided for all the 
LIFs. In a multiplexing operation, the LIF delimits valid 
frames including T1 frames, packets, cells, etc. The 
valid frames are then passed to the UIFs through the 25 
frame-based interface 900 such as UTOPIA (Universal 
Test and Operation Interface for ATM) or PCI (Peripheral 
Component Interconnect) interface. 
[0074] All protocol processing is performed in the UIFs 
which converts frames to ATM cells before passing 30 
them to a cell multiplexer card 902 in the upstream 
direction and vice versa in the down stream direction 
through an ATM cell bus 901 or UTOPIA. 
[0075] Similarly, in a demultiplexing operation, the cell 
multiplexer card 902 receives ATM cells from an ATM 35 
network and passes them to the UIF through the ATM 
cell bus 901 . At the UIF, the received ATM cells are con- 
verted to frames and they are then passed to the LIF 
through the frame-based interface 900. Finally, they are 
converted to suit appropriate line technologies. 40 
[0076] In Fig. 1 1 , the respective LIFs are connected to 
UIFs. It should be noted that several instances of UIFs 
are used but they are all of the same type. The UIFs, an 
element manager card 903 and the cell multiplexer card 
902 are connected to each other through the ATM ceil 45 
bus 901. The element manager card 903 and the cell 
multiplexer card 902 will be described in detail later. 
[0077] An advantage of this architecture is that cus- 
tomers can buy multiplexers without deciding the exact 
mix of line cards that need to be deployed. Furthermore, so 
as the demand grows, customers can add and delete 
line interface cards and the system will auto-configure 
itself based on the changes. The mix of services being 
offered by such an architecture is also completely pro- 
grammable and flexible. The mechanical arrangement 55 
of a platform embodying the present invention also 
allows for a stackable architecture allowing line interface 
cards and their corresponding modules to be added to 
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the system in a modular fashion. 
2. Physical implementation 

[0078] Referring to Fig. 1 2, for simplicity, it is assumed 
that a cell-based line card (ADSL LIF) 1001 and a non- 
cell-based line card (ADSL LIF) 1002 are connected to 
a UIF 1004, and a T1 LIF 1003 is connected to a UIF 
1005. Recognizing the usefulness of industry standard 
interfaces to couple a UIF and an LIF, and recognizing 
that both ATM-based cells and non ATM-based data 
arrive at the system, the UIF is designed to have two 
kinds of interfaces to couple with the LIF. These are the 
industry standard UTOPIA interface for a cell-based line 
card and a PCI interface for non cell-based line cards. 
The PCI bus also serves as a computer for intercon- 
necting LIF processor with UIF processors. 
[0079] The cell-based ADSL LIF 1 001 is connected to 
the UIF 1004 through both a UTOPIA interface 1006 for 
transfer of ATM-based cells and a PCI interface 1 007 for 
transfer of non ATM-based data. Through the PCI inter- 
face 1007, the non-cell-based ADSL LIF 1002 is con- 
nected to the UIF 1004. The T1 LIF 1003 is connected 
to the UIF 1005 through a PCI interface 1008. 
[0080] To use the UIF resources in this embodiment 
efficiently, multiple LIFs are allowed to home in on a sin- 
gle UIF allowing each UIF to process about 100 Mb/s of 
data. However, a flexible software architecture allows 
additional processing power on each UIF by treating the 
entire system as a multiprocessor system with the abil- 
ity to balance processing load on a traffic driven basis. 
[0081] The element management system card 903, 
the cell multiplexer 902, and a function server 906 are 
attached to the ATM cell bus 901. The cell multiplexer 
902 is connected to an ATM network 904. The element 
management system card 903 can be remotely man- 
aged using the remote management system 905. 
[0082] The PCI bus standard is augmented to provide 
hot-swapping capability by using the compact PCI 
standard with special tristate-able line drivers using the 
Texas Instruments LVTH family. The features of this 
logic family that is important for the present invention 
are: 

Low power consumption; 

Power-up tristate for hot insertion; 

Tristate, when not driving the bus for a lower overall 

load; 

• Fast propagation delays; and 

• Bus hold logic that eliminates the need for pull-up 
resistors. Such a result is achieved by having the 
bus receivers continue to drive the bus weakly at 
the same state, as the last unit to drive the bus, until 
it detects another driver on the bus drive it with 
another signal. 

[0083] The flexible universal access multiplexing sys- 
tem is organized in a hierarchical fashion. The element 
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management system card 903 which maintains a mas- 
ter copy of all databases and memory-maps communi- 
cates with the UIF CPUs through the ATM cell bus using 
a dedicated PVC for interprocessor communications. 
The UIF CPU in turn communicates with individual LIF 5 
CPUs through the PCI interface so as not to reduce the 
UIF performance. 

[0084] The following features may be incorporated on 
the above platform: 

TO 

1) Autoconfiguration of LIFs when they get plugged 
into the UIF slots; 

2) Dynamic protocol downloads on the UIF on a per 
session basis; 

3) Downloads from the ATM network 904 through 15 
the element management system card 903; 

4) Remote agents invocation on LIFs and UIFs; and 

5) A distributed object architecture to allow load 
sharing and location independent processing. 

20 

[0085] When the cell-based ADSL LIF 1001 is 
inserted and connected to the UIF 1004, the cell-based 
ADSL LIF 1001 is set to an operable state such that 
ATM-based cells are allowed to be transferred through 
the UTOPIA interface 1006 between them. When the 25 
non-cell-based ADSL LIF 1002 is inserted and con- 
nected to the UIF 1004, the non-cell-based ADSL LIF 
1002 is set to an operable state such that non ATM- 
based data are allowed to be transferred between them 
through the PCI interface 1007. As described before, 30 
the PCI interlace 1007 is also used as a computer bus 
to interconnect the processors of the LIFs 1001 and 
1002 with the processor of the UIF 1004. Similarly, 
when the T1 LIF 1003 is inserted and connected to the 
UIF 1 005, non ATM-based data are allowed to be trans- 35 
ferred between them through the PCI interface 1008. 
The PCI interface 1008 is also used as a computer bus 
to interconnect the processor of the LIF 1003 with the 
processor of the UIF 1 005. To use such a flexible univer- 
sal access multiplexing system efficiently, a set of mes- 40 
sages is used to communicate between a LIF and a UIF. 

UNIVERSAL INTERFACE CARD 

[0086] Referring to Fig. 13, the UIF is provided with a 45 
Utopia interface 1 101 which can be connected to a cell- 
based LIF through the UTOPIA 1006. The Utopia inter- 
face 1101 is connected to a cell memory 1102 and a 
header translation table 1103. The UIF includes a cell 
scheduler 1104, a Segmentation and Reassembly so 
(SAR) section 1 105, and a packet memory 1 106. 
[0087] Packets received from frame-based LIFs 
through the PCI bus are stored in the packet memory 
1106. The SAR section 1105 segments the packets 
stored in the packet memory 1 106 into cells and stores ss 
the cells onto the cell memory 1102. Conversely, cells 
received from the ATM cell bus 901 are stored onto the 
cell memory 1102. Then, the SAR section 1105 reas- 



sembles packets from the received cells and the pack- 
ets are transferred to the frame-based LIFs through the 
PCI bus. In the case of cell-based LIFs, outgoing and 
incoming cells are transferred through the Utopia inter- 
face 1101. The header translation table 1103 provides 
necessary information to determine the outgoing 
VPl/VCI for the cells coming in through the cell-based 
Utopia interface 1101 or through another Utopia inter- 
face 1110. These operations are controlled by a UIF 
CPU 1107 using Integrated Local Management Inter- 
face per VC Accounting section 808 and packet support 
tables 1109. 

1. Autoconfiguration 

[0088] When the LIF is plugged into the PCI slot of the 
UIF, the UIF autoconfigures the LIF. The UIF obtains the 
following information from the LIF: 

1) Line Protocol on the LIF. 

2) The data path, whether cell based through Utopia 
206 or frame based through PCI bus. 

3) The protocol stack that needs to be downloaded 
for using this LIF. Some of the choices for the proto- 
col stacks are: 

Frame Relay Over ATM. See The Frame Relay 
Forum, "Frame Relay/ATM PVC Service inter- 
working Implementation Agreement", FRF. 8, 
April 1995; and The Frame Relay Forum, 
"Frame Relay/ATM PVC network interworking 
Implementation Agreement", FRF5, December 
1994. 

• PPP over ATM. See RFC 2364, PPP Over 
AAL5, July.1998; 

• IP over ATM (RFC 1577, 1483). See M.Lau- 
bach., "Classical IP and ARP Over ATM", RFC 
1577, January 1994; and Heinanen.J., "Multi- 
protocol Interconnect Over AAL5", RFC 1483, 
July 1993. 

IP over ATM using MPOA. See Multiprotocol 
Over ATM Version 1 .0, The ATM Forum, July 
1997; 

IP over ATM using IP switching {Ipsilon, Tag, 
aggregate route based IP switching (ARIS), 
cell-switched routing (CSR), Ipsofecto}. See 
RFC 1953, "Ipsilon Flow Management Protocol 
Specification for IPv4, Version 1.0," May 1996; 
YRekhter et al., "Cisco Systems' tag switching 
architecture overview," IETF RFC 2105, Feb. 
1997; R.Woundy, "ARIS: Aggregate route- 
based IP switching," IETF Internet Draft, draft- 
woundy-aris-ipswrtching-00.txt, Nov. 1 996; 
YKatsube, K Nagami, and H Esaki, 'Toshiba's 
router architecture extensions for ATM: Over- 
view," IETF RFC 2098, Feb. 1997; and A. Ach- 
arya, R. Dighe. F. Ansari, "IPSOFACTO: IP 
switching over fast ATM cell transport," IETF 
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Internet Draft, draft-acharya-ipsw-fast-cefl- 
OO.txt, July 1997. 

• ATM Inverse Multiplexing. See Inverse Multi- 
plexing for ATM (IMA) specification version 1 .0, 
The ATM Forum, July 1997. 

• Circuit Emulation Protocol over ATM. See Cir- 
cuit Emulation Service Interoperability Specifi- 
cation Version 2.0, The ATM Forum, January 
1997. 

• Native ATM. See Native ATM Services: 
Semantic Description Version 1.0, The ATM 
Forum, February 1996. 

• VTOA. See Voice and Telephony Over ATM- 
ATM Trunking using AAL1 for Narrowband 
Services version 1.0, The ATM Forum, July 
1997 

Radio Technologies such as GSM over ATM 

[0089] There are two different scenarios for the auto- 
matically downloading protocol on the UIF 

.1. There is no signaling channel between the LIF 
and the customer premises equipment (CPE). 
2. There exists a signaling channel between the LIF 
and the CPE. 

[0090] It is to be noted that the signaling referred to 
here is not the traditional signaling associated with call 
setup and teardown but signaling related to associating 
a protocol stack with a given ATM VC. 
[0091] In the first case, it is assumed that a higher 
entity (like an NMS or a service order) has already 
stored protocol stack information on a per channel basis 
which can be used by the UIF for customizing protocol 
stacks on a per session basis. Note that higher level 
agents using languages like CORBA (Common Object 
Request Broker Architecture) are also able to make the 
changes needed to the UIF configuration registers 
through the element management system card 903. 
[0092] In the second case, the signaling mechanism 
can be explicit or implicit. In explicit signaling, a well- 
know channel on the LIF/CPE link carries these mes- 
sages while in the implicit case, channels 
(VCs/DLCIs/Slots) are partitioned to different protocol 
stacks. This channel partitioning is negotiated using 
Hello messages between the LIF and the CPE. If the 
signaling is explicit, a signaling channel is specified on 
the link between the CPE and the LIF. If the link sup- 
ports ATM, then a PVC is used to carry the protocol spe- 
cific information between the CPE and the Mutiplexer. 
The signaling PVC that is to carry user network inter- 
face (UNI) signaling (VP=0, VC=5), specifically the 
codeset 7 (User Specific lEs), can be used to indicate a 
nonstandard signaling message. 
[0093] A similar signaling channel can also be caned 
out of a T1 link by using the robbed bit signaling channel 
or a FR PVC or the D channel on a PRI and using the 
user specific PID. The signaling message carries infor- 



mation on the protocol to be used and will carry a proto- 
col id field in it. The LIF needs to store the signaling 
messages in a specific address location on its packet 
memory and inform the UIF about the location when it is 

5 plugged in. 

[0094] In the case that the link between the LIF/CPE 
actually has a standard signaling channel (ISDN, FR, 
Robbed bit, ATM UNI), the signaling message is 
extracted by the LIF and passed to the UIF using the 

10 aforementioned signaling location. The UIF terminates 
the signaling and transmission down the network based 
on the protocol stack that is relevant for the VC. 
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2. ATM Cell Level Functions 



[0095] The UIF performs ail the ATM level functions. 
This includes cell scheduling as well as per VC queuing 
performed by the cell scheduler 1104. Multiclass sup- 
port is assumed so the UIF terminates available bit rate 

20 (ABR) and processes resource management (RM) 
cells. Scheduling algorithms such as weighted round 
robin or strict priority or deadline scheduling is program- 
mable. Packet level support performed by the Packet 
Support Tables 1 109 includes per flow queuing as well 

25 as various packet discard schemes {early packet dis- 
card (EPD), partial packet discard (PPD), random early 
discard (RED)}. 

[0096] Shaping and policing functions are also per- 
formed. VC merge is an optional feature that needs 

30 hardware support for packet based scheduling. The 
SAR functions will also provide multi AAL support 
(AAL5, AAL1 and AAL2) for the different application 
types. This information needs to be provided on a per 
VC basis during the autoconf iguration stage or can be 

35 updated as VCs are set up on a call by call basis. 

3. Higher Level Functions 

[0097] The protocol stacks listed above is supported 

40 on the UIF in a modular downloadable fashion. The 
entire ATM signaling stack (UNI 4.0, PNN1 1.0) is down- 
loaded on the UIF if needed. The IP protocol stack 
{internet gateway management protocol (ICMP), 
resource reservation protocol (RSVP), border gateway 

45 protocol (BGP), open switch path first (OSPF), RIP, dis- 
tance vector multicast routing (DVMRP) etc.} is down- 
loaded on the UIF CPU 1107 or kept on a separate 
function server card 906. A modest size IP table look up 
cache 1 109 is maintained on the UIF CPU 1 107. Flow id 

so tables can be carved out from the system memory if IP 
switching schemes based protocol stacks are being 
used on a given UIF. The L3/L2 binding hardware is 
supported on the UIF. This takes a L3 address and pops 
out a L2 VC for that given address. The same hardware 

55 could be used for MPOA and other IP switching 
schemes. Based on the MPLS requirements, a 20-bit 
lookup table may be needed on the UIF. 
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4. Higher Level Remote Agents 

[0098] The UIF is also expected to support remote 
Jave/Corba agents from remote agents. The typical 
functions that these agents need to perform are: s 



Filtering Operations. 

Security Operations including encryption and 
decryption. 

Collecting Billing Data. 
Packing a specific VC to start a debug trace. 
Invoking a specific mobility support algorithms such 
as hand off support and location management. 



5. Database Support 



10 
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[01 04] On successful completion of the configuration, 
the LI F sends a configuration success/failure message 
back to the UIF. After the channel activation has been 
successfully completed and established the link with the 
remote CPE, the UIF identifies the remote CPE using 
line stabilization, identify remote and identify remote 
acknowledgement messages as will be described later 
and then sends a loopback message to the LIF. The 
loopback message causes the LIF to set up the loop- 
back test. The LIF sends an acknowledgement of the 
loopback message to the UIF and starts measurement. 
The collected statistics are sent by the LIF to the UIF in 
response to the request of the UIF. The statistics are 
reported to the UIF at predetermined intervals (here, 
every 1 second). 



[0099] The UIF maintains a copy of the interim link 
management interface (ILMI) and the ATMMIB data- 
base 1108. Other database support for IP switching 
schemes is also supported. The UIF allows both simple 20 
network management protocol (SNMP) and common 
management information protocol (CMIP) agents to 
query these databases. 



ELEMENTS MANAGEMENT SYSTEM CARD 



25 



[01 00] The elements management system card 903 is 
the master controller of the universal access multi- 
plexer. A CORBA ORB will resides on this card. This 
card communicates with the UIFs using ATM PVCs. It so 
also has CORBA-based PVC setup with remote net- 
work servers and databases. The elements manage- 
ment system (EMS) is expected to be carrier-ready and 
needs to support TMN interfaces to Operation Support 
Systems. It needs an X.25 interface to provide support 35 
for SS7 (Signaling System 7)-based systems. 

OPERATION 

[0101] For using the flexible universal access multi- 40 
plexing system as described above efficiently, a set of 
messages is required. An example of message commu- 
nications sequence will be described hereinafter. 
[0102] When a LIF is plugged into a UIF, the LIF 
makes a registration request to the elements manage- 45 
ment system (EMS) card 903. When the LIF has been 
registered in the EMS card 903, a registration response 
is sent back to the LIF. 

[0103] When receiving the registration response from 
the EMS card 903, the LIF makes a registration request so 
to the UIF using a Hello message as will be described 
later. The UIF determines whether the connected LIF is 
acceptable or not in response to the registration request 
and sends the result (accept or reject) to the LIF. If the 
LIF is acceptable, the UIF sends the LIF a configuration 55 
message conveying the correct configuration files to 
support the LIF, which have been downloaded from the 
EMS card 103. 



DISTRIBUTED CALL PROCESSING 

[0105] The present invention provides a software 
architecture for implementing open call control in multi- 
processor ATM switches. By implementing a set of well- 
defined control interfaces at the switch ports and at the 
signaling protocol objects the call processing load is dis- 
tributed within as well as outside the switch hardware. 
The present invention also provides a distributed 
processing framework which can be used for simultane- 
ous implementation of multiple signaling protocols 
within a switch. Multiple protocols are supported both at 
the port level and at the switch level. The architecture 
also supports dynamic protocol downloading which is 
useful when a switch does not require to pre-load all 
possible signaling protocols at boot time. Instead, it can 
download the necessary call-control modules on-the-fly, 
as required. This mechanism helps the processing and 
memory resources in the DSLAM switch to be utilized in 
an efficient manner. Finally, how the present architec- 
ture can work with a distributed network management 
system and is able to implement hierarchical switch 
management along with dynamic service creations is 
illustrated. 

[01 06] Other modifications and variations to the inven- 
tion will be apparent to those skilled in the art from the 
foregoing disclosure and teachings. Thus, while only 
certain embodiments of the invention have been specif- 
ically described herein, it will be apparent that numer- 
ous modifications may be made thereto without 
departing from the spirit and scope of the invention. Fur- 
ther, acronyms are used merely to enhance the reada- 
bility of the specification and claims. It should be noted 
that these acronyms are not intended to lessen the gen- 
erality of the terms used and they should not be con- 
strued to restrict the scope of the claims to the 
embodiments described herein. 

RESOURCE AND PROTOCOL MANAGEMENT FOR 
VPNs 

[0107] The present invention is partially based on a 
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network-control paradigm in which a VPN owner is 
allowed to run multiple control/signaling protocols within 
its own VPN. Support of such a multiprotocol control is 
an important feature of this invention. It allows different 
connections (belonging to a single VPN) on a single 5 
switch port to be controlled by different control proto- 
cols. 

[0108] This design can be implemented on an ATM 
open-control framework which is described above. The 
architecture provides a bottom-up mechanism for sup- 10 
porting resource partition and reservation within multi- 
processor switching devices. The architecture also has 
a clean mechanism for incorporating multiple control 
protocols on a switch port. A key aspect is the use of the 
port-resource management layer of the architecture for 15 
implementing VPN resource and protocol management 
functions. 

[0109] There are several key features that form the 
core of the present invention. According to the present 
invention, line-resources within the network are parti- 20 
tioned to provide VPN support. Further resources for 
switch processing functions are also partitioned for VPN 
support. The present invention also provides for mecha- 
nisms for reserving resources for individual VPNs. Mul- 
tiple control protocols can be configured on a single 25 
switch port. Mechanisms are provided for assigning 
control protocols to the VPNs. Another key aspect of the 
invention is the provision of management support for 
VPN service creation and deletion. 
[0110] As shown in FIG. 14, an overlay model forms 30 
the basis of the present embodiment. In this model two 
VPNs are created on an ATM network with five switches 
and eight links. The bold lines represent physical ATM 
links. VPN-1, spanning through switches S1, S2, S3 
and S4, is allocated to customer-1. This customer is 35 
present at site-1, site-2 and site-3. Similarly, VPN-2, 
which spans through S1 , S3 and S4, is assigned to cus- 
tomer^, who has presence at site-1 and site-3. Note 
that this VPN model allows a single customer to be 
present at more than one sites. The presence of a cus- 40 
tomer at more than one site makes it particularly suita- 
ble for corporate customers who require customized 
network services among multiple sites that are geo- 
graphically apart. Note that in the overlay framework 
that is described, an ATM switch can be shared by mul- 45 
tiple VPNs both at the switch level and at the port level. 
For example, the switch S1 is shared by both the VPNs. 
Further, two of its ports (port connecting site-1 and port 
connecting switch S3) are shared by the VPNs. Such a 
sharing requires resource partitioning, reservation and so 
management mechanism to be in place within the 
switch. The present invention specifically provides an 
architectural framework for both line and processor 
resource management for VPNs, acting on ATM 
switches. ss 
[01 1 1 ] Once a VPN is created, its owner customer can 
use either PVCs or SVCs (Switched Virtual Circuit) 
within the VPN. In case SVCs are chosen, the customer 



can also choose its own signaling protocol, e.g. Distrib- 
uted ATM signaling or UNNI/PNNI, for connection setup 
and other ATM control-plane operations. See M. Veera- 
raghavan, T. F. La Porta and W. S. Lai, "An Alternative 
Approach to Call/Connection Control in Broadband 
Switching Systems," IEEE Communications Magazine, 
November 1995, pp. 90-95; "ATM User Network Inter- 
face (UNI) Specification Version 4.0, AF-SIG- 
0061.000," ATM Forum, July 1996; and "Private Net- 
work-Network Interface Specification version 1.0, AF- 
PNNI-0055.000," ATM Forum, September 1996). If the 
customer wants to support packet based services like 
IP within the VPN, it is free to choose a specific Packet- 
based control protocol. 

[01 1 2] It should be emphasized that, once configured 
appropriately, a VPN customer can choose any signal- 
ing/control protocol without affecting the other VPNs 
that are sharing the same ATM links and switches. For 
example, in FIG. 14, customer-1 and customer-2 can 
use completely different signaling protocols for setting 
up SVCs within VPN-1 and VPN-2. Because of such a 
sharing, in addition to appropriately reserving resources 
and partitioning, the participating ATM switches are 
required to support multiple control protocols on the 
same switch port. 

[0113] In the next level of multiprotocol support, the 
present invention allows a single VPN to use multiple 
signaling/control protocols over a switch port. In such a 
scenario, different sessions within the same VPN can 
use different control protocols based on their specific 
performance requirements. This can be better 
explained with an example. Consider that customer-1 in 
FIG.14 has a machine connected to VPN- 1 in site-1. 
For an IP-Telephony session on that machine, the end- 
application might prefer to use a control protocol like IF- 
over-ATM using MPOA. See "Multi-Protocol Over ATM 
Version 1.0, AF-MPOA-0087.000," ATM Forum, July 
1 997. However, for World Wide Web (WWW) traffic from 
the same machine, the web applications might prefer an 
IP switching protocol like Ipsilon IP-Switching. See P. 
Newman et al, "Flow Switching: To Switch or Not to 
Switch," NSF Workshop on Internet Statistics 
Measurements, March 1996. In this situation, VPN-1 
needs to support both MPOA and Ipsilon protocol 
stacks on the port (corresponding to switch S1) which is 
connected to site-1 . The choice of different control pro- 
tocols is based solely on the application performance 
requirements. The VPN resource management and pro- 
tocol support architecture of the present invention 
allows this level of multiple protocol support within a sin- 
gle VPN. 

[01 14] The architecture of the present invention also 
provides the necessary management functions for cre- 
ating and terminating the VPNs dynamically. This 
involves creating and destroying resource modules 
within the switch ports. This invention, working with an 
open control architecture described in provides all the 
switch level functions which are required for supporting 
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the presented VPN model. 

1. Port Resource Management for Supporting VPNs 

[01 1 5] As shown in FIG. 1 5, an embodiment provides s 
a mechanism for VPN-specific partitioning of the switch 
port resources. A layer of software, namely the Port- 
resource Management Layer (PRML) 204, is provided 
between a line card LC and the signaling protocol 103 
which controls the line card. w 
[0116] The software interface PHAI (Port Hardware 
Access Interface) 101 is used for providing access to 
the low-level line card resources including VCI/VPI 
table, input/output buffers and the cell scheduling 
parameters. In addition, it is also possible to obtain the is 
line card configuration and various traffic and error sta- 
tistics information through this interface 101 . In general, 
given the right access permissions, any control entity 
can manipulate the line card resources through the 
PHAI interface 101. A similar interface SPAI (Signaling 20 
Protocol Access Interface) 102 implements the control- 
ler counterpart of PHAI. Using this interface 102, a line 
card delivers control messages to the signaling protocol 
module 103. For the protocol module, it also serves as 
a general-purpose mailbox through which various asyn- 25 
chronous alarm events from the line cards are deliv- 
ered. These two interfaces together, implement the 
basis for an Open Control paradigm within the ATM 
switch, as described before. 

[0117] The Port-resource Management Layer (PRML) 30 
204 provides a mechanism for logically partitioning the 
available resources and bundling them into VPN spe- 
cific Resource Modules or VPNRMs 205.1 to 205.3. 
Once partitioned, these resource modules are allocated 
to specific VPNs which are active on the port in ques- 35 
tion. The port-specific resources managed by the PRML 
are switching bandwidth, VPt/VCI space, input/output 
buffer space and local processing cycles required for 
cell-level scheduling. 

[0118] Based on a pre-defined policy (static and/or 40 
dynamic), the PRML partitions these resources and 
allocates a part of it to a VPNRM, whenever the VPNRM 
is created. Each VPNRM is owned by a specific VPN 
and the owner VPN is free to choose its own authentica- 
tion and security model for the access to the corre- 45 
sponding resources. In addition, a VPNRM exports a 
VPN-specific Secured Interface (VSSI) 206 which is 
used by the protocol signaling module 103 for control- 
ling the partitioned resources, owned by a VPN. A VSSI 
interface offers all the PHAI functionalities with added so 
inter-module security and resource protection as 
described before. 

[01 1 9] Each VPNRM is identified by three parameters, 
namely, its associated port-id, protocol-type and aVPN- 
id. While the port-id simply refers to the physical port on 55 
which the resource module is created, the protocol-type 
points to a particular type of signaling protocol module 
that should control that particular VPNRM. The VPN-id 
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indicates the identification of the VPN itself. Within the 
port-resource management layer (PRML) 204 corre- 
sponding to each port, there is a Port Resource Man- 
ager (PRM) 202 which is responsible for partitioning the 
. available resources and allocating them to the VPN- 
RMs. The PRM 202 is also responsible for creating, 
deleting and managing the resource modules. 
[0120] How all the components of the PRML 204 
cooperate is described herein. During the creation of a 
VPN, the port resource manager 202 corresponding to 
the port is informed about the signaling protocol which 
the VPN needs to use on that port. The port resource 
manager 202 also receives information about the 
amount of line card resources requested by the VPN. 
Based on this information, the PRM 202 creates a 
resource module and allocates the desired amount of 
line card resources to the newly created module. Then 
a resource module-to-protocol binding is established so 
that the resource module knows which protocol module 
to interact with for its control purposes. 
[0121] This point onwards, a VPNRM and its associ- 
ated signaling protocol module, together control and 
maintain the connections which arrive through the resid- 
ing port and belong to the logical network, owned by 
that particular VPN. Inter-VPNRM resource violations 
are trapped at this layer and appropriate corrective 
actions are taken. Upon receiving the termination 
instruction from higher layer management entities, the 
port resource manager deletes the corresponding VPN- 
RMs. In this scenario, such a termination request hap- 
pens when the VPN decides to withdraw services from 
this particular port of the switch. Once a resource mod- 
ule is terminated, its resources are reclaimed by the 
port resource manager and are used for reallocation to 
VPNRMs to be created in future. 

2. Multiprotocol Implementation 

[0122] As shown in FIG. 16, the VPN resource man- 
agement layer can support multiple protocols. A list of 
supported signaling protocols is the same as the list 
described in FIG. 4. 

[0123] There is no one-to-one coupling between a 
particular signaling protocol module and a VPNRM on 
the port. Multiple VPNRMs can use a single protocol 
module to execute their signaling requirements. The 
reverse however is not true; meaning a VPNRM is never 
allowed to communicate with multiple protocol modules 
even if their protocol types are same. Since different 
VPNRMs can be controlled by different signaling proto- 
cols, the first signaling requirement of the VPN model is 
satisfied within this architecture. That is, each VPN can 
choose its own control protocol without affecting the 
operations of the other VPNs operating on the same 
switch port. 

[0124] The second requirement of the VPN model is 
to let a VPN use multiple control protocols on the same 
switch port. To incorporate this, a single VPN can create 
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multiple VPNRMs on the same switch port, depending 
on its control protocol requirements. Assume that a 
VPN needs to support both MPOA and Ipsilon IP- 
Switching protocols on the same switch port. This can 
be achieved by creating two VPNRMs and associating 5 
one with an MPOA protocol signaling module and the 
other with an IF-Switching module. Whenever a 
VPNRM gets registered with a protocol object, it sends 
its own allocated resource information to the protocol 
module. The control protocol module uses this resource to 
information to allocate several items to the connections, 
belonging to the resource module, including VPI/VCI, 
Buffers, Cell-level scheduling priority and Call Admis- 
sion Control (CAC). 

[01 25] The above mechanism assures the protection is 
of inter-VPNRM resources when multiple VPNRMs are 
controlled by a single signal protocol module. 
[0126] In order for this multiprotocol VPN framework 
to work, a clean mechanism for demultiplexing signaling 
messages at the line card hardware level is required. 26 
When a connection setup message is received, the line 
card hardware is required to deliver the message to the 
appropriate VSSI interface. This is done through the 
appropriate VPNRM. First a decision needs to be made 
regarding which VPN this signaling message belongs 25 
to. Then a specific VPNRM should be chosen, based on 
specific control requirement. 
[0127] The first level of demultiplexing is done by par- 
titioning the available signaling VPI/VCI space of a par- 
ticular switch pod. Consider a scenario where two VPNs 30 
need to run UNI/NNI signaling on a single switch port 
but each require independent control on their respective 
VPNRMs. This is achieved by partitioning the signafing 
VPI/VCI space for different owners. An example of this 
would be the use VPI 0, VCI 5 as the signaling channel 35 
for VPN-1 and the use of VPI 0, VCI 6 as the signaling 
channel for VPN-2. This partition information is con- 
veyed to the switches during the configuration of the 
VPNs during their creation. The second level of demul- 
tiplexing, that is the selection of a specific VPNRM 40 
within the chosen VPN, is performed by using additional 
information within the control message itself. The 
present invention uses additional Information Elements 
(IE) within the signaling/control message for encoding 
the specific control protocol requirements. This informa- 45 
tion, together with the signaling VPI/VCI space parti- 
tion, is used for dispatching an incoming signaling 
message to its corresponding appropriate VPNRM. 

VPN ON UNIVERSAL ATM ACCESS MULTIPLEXERS so 

[0128] FIG. 1 7 depicts an integrated picture of all the 
necessary software components, running on multiple 
ports of the access multiplexer which has the same 
hardware configuration as shown in FIG. 10. The ss 
descriptions thereof will be omitted with the similar cir- 
cuit blocks labeled the same reference numerals. 
[0129] Three new software components, namely, a 



Central Protocol Manager Module (CPMM) 410, an 
Inter Object Messaging Platform (IOMP) 401 and an 
NMS agent 411 are shown in Fig. 17. Each ATM Multi- 
plexer contains a CPMM 410 which is responsible for 
protocol downloading, internal processing and memory 
resource administration and other protocol related man- 
agement activities. Each PRM 202 talks to the CPMM 
410 through a special management interface. This inter- 
face is used for notifying a PRM about the necessary 
VPNRMs and their resource requirement information. 
The IOMP 401 provides a uniform inter-module commu- 
nication interface within the ATM Multiplexer. This pro- 
vides a clean function-call type communication 
interface. For implementing IOMP, a combination of per- 
manent virtual circuits, operating system Inter Process 
Communication (IPC) calls, raw IP messages and 
Remote Procedure Calls (RPC) are used. 
[0130] The NMS agent 41 1 runs within the element 
manager card 903 and communicates with a desig- 
nated NMS manager which resides within the network 
904. The role of NMS agent 411 is to coordinate local 
network management operations including VPN man- 
agement, protocol downloading, device configuration, 
resource configuration, measurement and billing. More 
about VPN management by NMS agent is discussed in 
the next section. 

VPN Management 

[0131] Another aspect of the present invention is a 
switch resource and protocol management architecture 
for supporting Virtual Private Networks. Previous sec- 
tions of this documents describe various components of 
the architecture and their interworking within a switching 
device. In this section, a mechanism for an external 
entity like a Network Management System (NMS) to 
create and configure the VPN support components 
within the switch is provided. 
[01 32] As shown in FIG. 1 8, the process of VPN cre- 
ation/configuration is described as a sequence diagram. 
The circled numbers attached to each dotted arrow indi- 
cates the sequence of that operation. Note that the step 
number in the following description corresponds to the 
operation sequence number in the diagram. It is to be 
noted that all the internal communication is performed 
using the IOMP mechanism, described earlier. 

1. An NMS manager 905 instructs the switch NMS 
agent 41 1 to create a VPN. This instruction comes 
with various VPN specific information, including 
VPN owner id., participating switch ports, duration 
of the VPN and required signaling/control protocols 
on each port. Usually, this process is triggered 
when a customer needs to create a VPN and con- 
tacts the NMS with its specific requirements. Note 
that a similar request can also be originated for 
reconfiguring/modifying an existing VPN. 

2. The NMS agent 41 1 performs the authentication 



17 



33 



EP0 977 457 A2 



34 



validation of the request and forwards it to the Cen- 
tral Protocol Manager Module (CPMM) 410. At this 
stage, the CPMM 410 processes the request and 
decides which ports are required to be configured 
by the VPN. 

3. The CPMM 410 sends configuration requests to 
all the Port Resource Managers (PRMs) 202 of the 
involved ports. For simplicity, transaction with only 
one port is shown in the FIG. 18. However in reality, 
similar transaction is carried out between the 
CPMM 410 and all the appropriate PRMs. Detailed 
resource and protocol requirements are sent to the 
PRMs at this stage. 

4. Tlie PRM 202 creates and configures required 
VPNRMs 205 with specified amount of resources 
reserved for them. If a sufficient amount of 
resources is not available, then the PRM 202 gen- 
erates a fault message back to the CPMM 410 
which is finally relayed back to the appropriate cus- 
tomer through the network management system. 

5. The PRM 202 communicates with the CPMM 
410 to get a reference for the desired control proto- 
col module within the switch. The CPMM 410 main- 
tains a database of all such locally resident control 
modules. If the desired module is not available, 
then the CPMM 410 downloads the required signal- 
ing module from the network. The download proc- 
ess is designed as described before. At this stage, 
the CPMM 410 provides the PRM 202 with a refer- 
ence to the desired control protocol module. 

6. The PRM 202 passes the VPNRM configuration 
information to the necessary protocol signaling 
module 103. 

7. A binding is created between a VPNRM 205 and 
its control protocol signaling module 103. 

Although the figure shows only one such 
instance, this operation is performed for all the cre- 
ated VPNRMs and their designated protocol signal- 
ing modules. 

8. Control message demultiplexing information is 
sent to the switch line card. This information is used 
at the PHAI interface level for dispatching an incom- 
ing control message to the appropriate VPNRM. 

9. Success or failure of the process is sent back to 
the CPMM 410. 

10. Information conveyed in the step indicated by 
the reference numeral 9 is sent back to the NMS 
agent 41 1 . 

11. Information conveyed in the step indicated by 
the reference numeral 10 is sent back to the NMS 
manager 905 which, in turn, informs the initiating 
customer about the result of the VPN set up proc- 
ess. 

[01 33] Note that this architecture is capable of execut- 
ing this entire process dynamically and that is without 
affecting the operations of the existing VPNs which 
were already configured on the switch. 



[01 34] Other modifications and variations to the inven- 
tion will be apparent to those skilled in the art from the 
foregoing disclosure and teachings. Thus, while only 
certain embodiments of the invention have been specrf- 

5 ically described herein, it will be apparent that numer- 
ous modifications may be made thereto without 
departing from the spirit and scope of the invention. 
[01 35] Further, acronyms are used merely to enhance 
the readability of the specification and claims. It should 

10 be noted that these acronyms are not intended to 
lessen the generality of the terms used and they should 
not be construed to restrict the scope of the claims to 
the embodiments described herein. 

15 Claims 

1. An open control system for an ATM network includ- 
ing a plurality of ATM switches, characterized by: 

20 a port hardware access interface (PHAI) pro- 

viding access to line card resources; and 
a signaling protocol access interface (SPAI) 
which is connected to a signaling protocol mod- 
ule and implements switch controller function- 
25 ality, 

wherein the PHAI and the SPAI communicate 
with each other using at least one mechanism 
depending on a processing platform used. 

30 2. The open control system according to claim 1, fur- 
ther comprising a port resource manager layer 
(PRML) between the PHAI and the SPAI, for logi- 
cally partitioning available resources and bundling 
the available resources into logically consistent 

35 resource modules. 

3. The open control system according to claim 2, 
wherein the available resources includes switching 
bandwidth, VPI space, VCI space, input buffer 

40 space, output buffer space and local processing 
cycles for cell-level scheduling. 

4. The open control system according to claim 2 or 3, 
wherein the PRML partitions the available 

45 resources based on one of a static and/or dynamic 
policy into a plurality of partitioned resource mod- 
ules, wherein each of the plurality of partitioned 
resource modules is assigned to a specific adminis- 
trative entity. 

50 

5. TTie open control system according to claim 4, 
wherein each of the plurality of partitioned resource 
modules exports a module specific secured inter- 
face (MSSI) that is used by a protocol signaling 

55 module for controlling the plurality of partitioned 
resource modules. 

6. The open control system according to claim 4, 
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wherein partitioning the available resources is done 
by a port resource manager (PRM), wherein the 
PRM receives information about the signaling pro- 
tocol that will be used by a newly created adminis- 
trative entity on a specific port and an amount of 5 
line card resources required by the administrative 
entity, wherein based on received information the 
PRM creates a partitioned resource module and 
allocates a desired amount of resources to the 
newly created administrative entity. w 

7. The open control system according to claim 4, 
wherein the partitioned resource modules are fur- 
ther coupled with at least one signaling protocol 
module, the signaling protocol module being line 15 
independent to provide location transparency, 
wherein associations are created between said par- 
titioned resource modules and said one or more of 
signaling modules such that multiple partitioned 
resource modules can be associated with a single 20 
signaling module but multiple signaling modules 
can not be associated with a single partitioned 
resource module, wherein said coupling is provided 

to execute signaling requirements. 

25 

8. The open control system according to claim 5, 
wherein a signaling message dispatching mecha- 
nism is provided within the PHAI, wherein when a 
line card corresponding to the PHAI receives a con- 
nection setup message, the connection setup mes- 30 
sage is delivered to the corresponding MSSI 
through the corresponding partitioned resource 
module by partitioning an available VPI space and 
VCI space of a corresponding port. 

35 

9. The open control system according to claim 6, fur- 
ther comprising a protocol manager module (PMM) 
for each switch, wherein the PMM is responsible for 
protocol downloading, internal processing, and 
memory resource administration and management 40 
plane activities. 

10. The open control system according to claim 7, 
wherein the at least one signaling module commu- 
nicates with an inter object messaging platform 45 
(IOMP), wherein the IOMP provides a uniform com- 
munication interface between said at least one sig- 
naling module. 

11. The open control system according to claim 9, so 
wherein the PMM communicates with the PRM 
through a special management interface, wherein 

the management interface is used for indicating to 
the PRM the necessary resource modules and the 
corresponding resource requirements. ss 

12. The open control system according to claim 2, 
wherein the PRML provides a mechanism for logi- 



cally partitioning available resources and bundling 
a partitioned resource into VPN (virtual private net- 
work) specific resource module (VPNRM), the 
VPNRMs being allocated to at least one VPN which 
is overlaid on the ATM network. 

13. The open control system according to claim 12, 
wherein each of the VPNRMs is owned by one of 
the VPNs and the one of the VPNs is free to choose 
an authentication and security model for accessing 
available resources. 

14. The open control system according to claim 12, 
wherein each of the VPNRMs exports a VPN-spe- 
cific secured interlace (VSSI), the VSSI being used 
by a protocol signaling module for controlling parti- 
tioned resources owned by a VPN. 

15. The open control system according to claim 12, 
wherein each of the at least one VPN is capable of 
using multiple control protocols on a same switch 
by creating a VPNRM each for each of the multiple 
control protocols. 

16. The open control system according to claim 12, 
wherein each of the at least one VPN uses an inde- 
pendent control protocol on a switch by creating a 
VPNRM for the independent control protocol. 

17. The open control system according to claim 12, 
wherein each of the VPNRMs is registered with a 
protocol object by sending an allocated resource 
information corresponding to the VPNRM to a pro- 
tocol module, wherein the protocol module uses the 
resource information to allocate resources. 

18. The open control system according to claim 12, 
wherein when a connection setup message is 
received, a line card hardware delivers the connec- 
tion setup message to an appropriate VSSI inter- 
face through an appropriate VPNRM, the 
appropriate VPNRM being chosen based on a spe- 
cific control requirement corresponding to a VPN 
associated with the connection setup message. 

19. The open control system according to claim 18, 
wherein a VPNRM is chosen by partitioning an 
available VPI space and VCI space of a switch port 
and selecting a VPNRM within the VPN associated 
with the message using additional information 
within the message itself. 

20. The open control system according to claim 1 2, fur- 
ther comprising a network management system 
(NMS) on the ATM network and an NMS agent that 
runs within an element manager card provided in 
an ATM switch, wherein the NMS agent and NMS 
manager communicate with each other and the 
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NMS agent coordinates local network management 
operations including VPN management, protocol 
downloading, device configuration, resource config- 
uration, measurement and billing. 

5 

21 . An open control system for a multiprocessor ATM 
switch in an ATM network including a plurality of 
multiprocessor ATM switches, characterized by: 

a port hardware access interface (PHAI) pro- io 
viding access to line card resources; and 
a signaling protocol access interlace (SPAI) 
which is connected to a signaling protocol mod- 
ule and implements switch controller function- 
ality, 15 
wherein call processing is distributed across a 
plurality of processors within the multiproces- 
sor ATM switch with load balancing and sharing 
and protocol downloading dynamically pro- 
vided, wherein the PHAI and the SPAI commu- 20 
nicate with each other using at least one 
mechanism depending on a processing plat- 
form used. 

22. The open control system according to claim 21, 25 
wherein a plurality of protocol modules are distrib- 
uted across line cards and switch controllers for 
achieving call processing load balancing. 

23. The open control system according to claim 22, 30 
wherein the load balancing is done by exploiting 
line independence of the plurality of protocol mod- 
ules, wherein when a line card faces a bottle-neck a 
new protocol module is initiated on a different line 
card and the new line card remotely controls the 35 
line card facing the bottle-neck. 

24. The open control system according to claim 21, 
wherein the PHAI and the SPAI communicate using 
one of a combination of virtual path and virtual 40 
channel, a bus-based communication mechanism 
and a distributed message passing mechanism. 

25. The open control system according to claim 21, 
wherein call control is independent of location and 45 
the call control can be performed remotely. 

26. The open control system according to claim 24, 
wherein the distributed message passing mecha- 
nism is at least one remote procedure call. so 

27. The open control system according to claim 24, 
wherein the distributed message passing mecha- 
nism is an object resource broker (ORB). 

55 

28. The open control system according to claim 24, 
wherein the distributed message passing mecha- 
nism is done using operating system primitives. 



29. An open control method for distributed signaling for 
ATM switches in the ATM network, wherein protocol 
modules are distributed across available proces- 
sors on line cards and switch controllers in a modu- 
lar fashion, characterized by the steps of: 

(a) receiving a connection request at an incom- 
ing port; 

(b) sending a corresponding message to a 
UNt/NNI module; 

(c) executing call admission control at the 
UNt/NNI module for the incoming port; 

(d) making the call admission control decision 
based on available quality of service; 

(e) making routing decision for output port; 

(f) contacting a UNI/NNI module for the output 
port; 

(g) repeating steps c-d for the output port; and 

(h) sending a connection request to next hop 
switch. 

30. An open control method for creating at least one 
VPN which is overlaid on the ATM network com- 
posed of a network management system (NMS) 
manager and a plurality of ATM switches each hav- 
ing a central protocol manager module (CPMM) 
and an NMS agent therein, wherein a port hard- 
ware access interface (PHAI) provides access to 
line card resources, a signaling protocol access 
interface (SPAI) is connected to a signaling protocol 
module and implements switch controller function- 
ality, a plurality of port resource managers (PRMs) 
logically partitions available resources and bundling 
a partitioned resource into VPN (virtual private net- 
work) specific resource module (VPNRM), the 
VPNRMs being allocated to at least one VPN which 
is overlaid on the ATM network, characterized by 
the steps of: 

instructing the NMS agent by the NMS man- 
ager for creating the VPN and providing VPN- 
specific information; 

performing authentication and validation by the 
NMS agent and forwarding a request to the 
CPMM; 

sending configuration request from the CPMM 
to the plurality of PRMs; 
configuring the plurality of VPNRMs by the 
PRMs with specified amount of resources 
required and sending a fault message if the 
resources are not available; 
communicating with the CPMM by the PRMs to 
obtain a reference for a desired control protocol 
module for a switch; 

passing the VPNRM configuration information 
by the PRMs to the signaling protocol module; 
creating binding between the VPNRMs and 
corresponding signaling modules; 
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sending control message demultiplexing infor- 
mation to the line card; and 
sending information on one of success and fail- 
ure to the CPMM, NMS agent and NMS man- 
ager, s 
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